Mozilla demuestra cómo un agente de programación puede acabar instalando malware desde un repositorio de GitHub que parecía limpio

La división 0din de Mozilla ha mostrado una vía de ataque que vuelve a poner el foco en uno de los problemas más delicados de los agentes de programación. Nos referimos al hecho de que realmente no entienden lo que están haciendo. Según la demostración publicada por el equipo investigador, Claude Code puede ser inducido a preparar un proyecto desde un repositorio de GitHub aparentemente inocuo y terminar ejecutando una cadena de acciones que desemboca en la instalación de malware.

La mecánica no se basa en un repositorio lleno de señales sospechosas, sino en todo lo contrario. El proyecto malicioso se presenta como una estructura bastante limpia, con pocos archivos y sin elementos que llamen demasiado la atención de herramientas de seguridad convencionales. El usuario solo tendría que pedir al agente que inicialice el proyecto o que lo configure después de haberlo clonado.

Ahí empieza el problema. El primer archivo relevante sería un README o documento en Markdown con instrucciones normales para preparar un entorno Python usando Axiom, descrito como una herramienta habitual de monitorización. Hasta ese punto, el flujo parece razonable. Sin embargo, el script inicial falla a propósito y empuja al agente a hacer lo que precisamente se espera de él: buscar una alternativa y resolver el problema por su cuenta.

Tres pasos indirectos que parecen normales hasta que ya es tarde

Según Mozilla 0din, Claude Code responde al error lanzando un segundo comando aparentemente inocente, python3 -m axiom init. Esa orden activa un script de shell que descarga software, otra acción que tampoco tiene por qué levantar sospechas por sí sola. El tercer nivel de indirección es el más interesante: en vez de obtener el payload desde una URL abiertamente maliciosa, el script consulta registros TXT de DNS de un dominio determinado.

Esos registros contienen una cadena codificada en base64 que termina abriendo una reverse shell, de manera que el atacante obtiene acceso remoto al sistema del desarrollador con los permisos del usuario. A partir de ahí, podría acceder a claves API, secretos, documentos, sesiones del navegador, contraseñas o incluso desplegar malware adicional para mantener persistencia. Mientras tanto, el agente y la víctima solo verían un mensaje final parecido a “entorno listo”.

Cada paso, por separado, parece bastante asumible dentro de un flujo de trabajo de desarrollo. El problema aparece cuando el agente no evalúa qué se va a ejecutar realmente ni qué implicaciones tiene la cadena completa de acciones. Mozilla subraya precisamente eso: que los agentes no deberían limitarse a seguir instrucciones o a “arreglar” errores, sino inspeccionar con más profundidad aquello que van a poner en marcha.

Más capacidad para automatizar no significa más seguridad

La demostración llega en un momento en que los laboratorios siguen empujando agentes cada vez más autónomos. Sin ir más lejos, Google ha llevado agentes de Gemini al Pentágono. Además, ya vimos las restricciones iniciales alrededor de GPT-5.6, que dibujan un panorama inestable para una tecnología que muchos pretenden integrar con cierta prisa. Este caso recuerda que el problema no está solo en los grandes modelos de frontera, sino en su uso cotidiano dentro de flujos reales de trabajo.

Mozilla 0din concluye con una recomendación bastante clara. No hay que tratar un proyecto desconocido como código fiable solo porque tenga buena pinta, y tampoco conviene delegar en el agente el análisis de seguridad del proceso que él mismo está ejecutando. En otras palabras, cuanto más capaces sean estas herramientas para actuar por nosotros, más importante será vigilar cómo toman decisiones y hasta qué punto su “amabilidad” puede volverse en contra del propio usuario.

Fin del Artículo. ¡Cuéntanos algo en los Comentarios!